<div id="Multiple-developers"></div>
<div class="header">
<p>
Next: [[cvs: Revision management#Revision management|Revision management]], Previous: [[cvs: Handling binary files#Handling binary files|Binary files]], Up: [[cvs#Top|Top]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>

----

<div id="Multiple-developers-1"></div>
== Multiple developers ==
<div id="index-Multiple-developers"></div>
<div id="index-Team-of-developers"></div>
<div id="index-File-locking"></div>
<div id="index-Locking-files"></div>
<div id="index-Working-copy"></div>
<div id="index-Reserved-checkouts"></div>
<div id="index-Unreserved-checkouts"></div>
<div id="index-RCS_002dstyle-locking"></div>

When more than one person works on a software project
things often get complicated.  Often, two people try to
edit the same file simultaneously.  One solution, known
as <em>file locking</em> or <em>reserved checkouts</em>, is
to allow only one person to edit each file at a time.
This is the only solution with some version control
systems, including <small>RCS</small> and <small>SCCS</small>.  Currently
the usual way to get reserved checkouts with <small>CVS</small>
is the <code>cvs admin -l</code> command (see [[cvs: admin options#admin options|admin options]]).  This is not as nicely integrated into
<small>CVS</small> as the watch features, described below, but it
seems that most people with a need for reserved
checkouts find it adequate.
It also may be possible to use the watches
features described below, together with suitable
procedures (not enforced by software), to avoid having
two people edit at the same time.

The default model with <small>CVS</small> is known as
<em>unreserved checkouts</em>.  In this model, developers
can edit their own <em>working copy</em> of a file
simultaneously.  The first person that commits his
changes has no automatic way of knowing that another
has started to edit it.  Others will get an error
message when they try to commit the file.  They must
then use <small>CVS</small> commands to bring their working copy
up to date with the repository revision.  This process
is almost automatic.

<small>CVS</small> also supports mechanisms which facilitate
various kinds of communication, without actually
enforcing rules like reserved checkouts do.

The rest of this chapter describes how these various
models work, and some of the issues involved in
choosing between them.


 [[cvs: File status#File status|&bull; File status]]::                 A file can be in several states
 [[cvs: Bringing a file up to date#Bringing a file up to date|&bull; Updating a file]]::             Bringing a file up-to-date
 [[cvs: Conflicts example#Conflicts example|&bull; Conflicts example]]::           An informative example
 [[cvs: Informing others about commits#Informing others about commits|&bull; Informing others]]::            To cooperate you must inform
 [[cvs: Several developers simultaneously attempting to run CVS#Several developers simultaneously attempting to run CVS|&bull; Concurrency]]::                 Simultaneous repository access
 [[cvs: Mechanisms to track who is editing files#Mechanisms to track who is editing files|&bull; Watches]]::                     Mechanisms to track who is editing files
 [[cvs: Choosing between reserved or unreserved checkouts#Choosing between reserved or unreserved checkouts|&bull; Choosing a model]]::            Reserved or unreserved checkouts?


----

<div class="header">
<p>
Next: [[cvs: Revision management#Revision management|Revision management]], Previous: [[cvs: Handling binary files#Handling binary files|Binary files]], Up: [[cvs#Top|Top]] &nbsp; |[[cvs: Index#SEC_Contents|Contents]]||[[cvs: Index#Index|Index]]|</p>
</div>
This document was generated on <i>a sunny day</i> using [http://www.nongnu.org/texi2html/ <i>texi2html</i>].
